fix(core): read find() answers as QueryResult declares them in extractRecords - #8436

Fixes #6839

Remove the records arm from the shared extractRecords normaliser
(packages/core/src/utils/extract-records.ts) and pin the contract read per
module. All work measured on 5dc25e3f5, the branch's only commit.

QueryResult (@object-ui/types) declares exactly one rows member, data.
The ladder was array -> records -> data -> value, i.e. the undeclared
spelling ahead of the contract's own member — the precedence inversion
#5945 was filed about and #6726 repaired by hand at seven other seams. It is
now array -> data -> value.

1. What the card got wrong, re-derived on this base

The card was measured on 26896c689 (#6726's base) and is stale in three
places. Every number below was re-derived on 0203a29e9.

No renderer had been fixed since filing — all nine are still live consumers.

⇒ The card's architecture question ("A: split it, or B: hand it rows") is
moot: there is one seam. No escalation is owed under the dispatch's fence —
the two arms are not both legitimate on different driver answers, because
nothing at this seam produces records at all.

2. Producer measurement, per consumer

Cell, stated: every object-literal records: key in every tracked
.ts/.tsx/.js/.jsx/.mjs file (143 hits / 103 files) — a complete population for
literal-form envelopes, with no body-scanner blind spot — plus three separate
sweeps for the shapes #6839's own thread warns a body-scanner cannot see:
mockResolvedValue-argument envelopes, brace-less arrow find bodies, and
computed/bracket-assigned keys.

Result: zero records envelopes reach any of the ten call sites. Per
package, the records: occurrences are doc comments, parameter names
(aggregateRecords(records: any[]), buildForest(records),
.then((records: any) =>), bare-array locals passed as
mockResolvedValue(records), and record-visibility batch route stubs
(fetch, not find).

Controls, so the zero is a reading and not a miss — the same sweeps are hot
elsewhere:

• mockResolvedValue cell: subject records at a DataSource.find double = 0;
  control data = 102 files; control value = lit.
• brace-less arrow find bodies: subject = 1 real hit,
  plugin-list/src/__tests__/ObjectGallery.expandFls-7429.test.tsx:117,
  find: vi.fn(async () => ({ records: [ROW] })). That producer feeds
  ListView's own unwrap ladder (ListView.tsx:2060-2067), which does not
  come through this helper. So the sweep demonstrably finds a producer of this
  exact shape when one exists.
• computed keys: subject 0, control data lit.
• records at the seams below the adapters is unchanged and untouched:
  ObjectStackAdapter.normalizeQueryResult, ApiDataSource .normalizeQueryResult (its ['data','items','results','records','value']
  loop), ViewDataProvider's private reader, apiAccessDenied.test.ts's
  client-SDK doubles, consoleUserPreferenceBudget.test.tsx's ds.client.data .find.

3. The value arm stays

#6840 / PR #6916 deleted value from ObjectView's ladder on a measured zero
at that seam and stated that its zero must not transfer here. Re-measured:
all five find() doubles it named still exist and still emit { value: [...] }
into this helper — plugin-kanban x3, plugin-calendar x2 (the calendar pair
now arrives through applyNonGridRowCeiling). Deleting it would break them.
That is a separate card with its own measurement.

QueryResult is not widened to bless records: published-type change,
maintainer's call, same floor #6726 and #6840 respected.

4. The pins — eleven files, 56 cases

One per module, named *.contractEnvelope-6839.*, in #6726/#6916's form: the
live arms are asserted alongside the deleted one, through the same mount,
because live and dead is the whole distinction.

5. Ablation — three legs, from the committed tree

Harness: absolute paths, trap ... EXIT INT TERM, restore by
git checkout HEAD -- path (never the bare form, which restores from the index
— i.e. from the mutation). Mutation proven on disk by printing the function body
and by hash; an empty hash is treated as failure, and a mutated hash equal to
the HEAD blob aborts the leg as a no-op. Restore proven by state: hash equal
to the HEAD blob AND git diff HEAD empty. No exit code is used as proof
anywhere.

git rev-parse HEAD:packages/core/src/utils/extract-records.ts =
d36ba54fe055c91ebe4afc91de8f10316ddc7bf4

Module resolution note: the root vitest.config.mts aliases @object-ui/core
to packages/core/src, so every leg resolves to source — no package
exports hop, no dist, and therefore no rebuild leg to get wrong.

Baseline (unmutated): VERDICT command-exit 0 — 11 files / 56 passed.

Restore verified after every leg: blob back to d36ba54f..., git diff HEAD
empty.

Leg A reddens by name, and only on the arm: every failing row is a
does NOT read records case, plus the three order cases —
data OUTRANKS records: a producer emitting both is read as QueryResult,
value outranks records too, and
a refused records envelope reports NOT truncated. Every live-arm case stayed
green.

Leg B answers the #8350 question directly: would an implementation strictly
worse than the bug pass these pins? No. A helper that returns [] for
everything reddens in all eleven files (35 cases), because every module has
at least one non-regression case pushing the same rows through the same mount.
The cases that stay green under B are exactly the refusal cases — which is the
proof they are not the whole pin.

Leg C separates "reorder" from "delete", the distinction the card's own
title invites. A mere reorder makes data OUTRANKS records green (the failing
list does not contain it) while all ten does NOT read records refusals stay
red, plus value outranks records too — because a reorder leaves the
undeclared spelling reachable whenever data is absent, which is precisely the
tolerance AGENTS.md #0.1 is about.

6. Verification (all at 5dc25e3f5)

Run through the container's shared heavy-verify lock; verdicts quoted from the
entry point, never a bare $?.

• Full suites of the ten consumer packages, in two runs:
  os-verify-lock: VERDICT command-exit 0 — 306 files / 4473 tests passed
  (core, react, plugin-charts, plugin-timeline, plugin-kanban) and
  VERDICT command-exit 0 — 227 files / 1778 tests passed
  (plugin-dashboard, plugin-gantt, plugin-calendar, plugin-map, plugin-tree).
• turbo run type-check over the same ten (tsc --noEmit && tsc -p tsconfig.test.json each): VERDICT command-exit 0 — 26/26 tasks. The new
  pins are proven to be in the program they are quoted from:
  tsc -p tsconfig.test.json --listFiles names
  extract-records.contractEnvelope-6839.test.ts (1 of 671) and
  ObjectGantt.contractEnvelope-6839.test.tsx (1 of 1486), each with a lit
  control and, for core, a negative control that is correctly absent.
• turbo run lint over the same ten: VERDICT command-exit 0 — 11/11 tasks,
  0 errors.
• Gates green: check-changeset-presence ("1 source file(s) of 1 released
  package(s) changed, and this change declares 1 changeset(s)"),
  check-changeset-no-major, type-check coverage (42/42 packages compile
  their tests), check-vi-mock-inherit, check-vi-mock-specifiers,
  check-control-bytes, check-phantom-dependencies,
  check-unused-dependencies, check-unreferenced-sources,
  check-package-self-import, check-lint-rule-coverage,
  check-element-data-source-declaration, check-comment-mask-corpus.
  check-governed-queue-guard --test on the 13 changed paths:
  NOT GOVERNED.

Not measured locally, declared to CI, and reported as NOT MEASURED rather
than as a pass or a failure — three gates need a built tree this worktree does
not have, and each says so in its own words: check-readme-exports
("run pnpm build first"; its own census reports 21 unbuilt packages and its
population-collapse guard fires), check-eager-closure and
check-sdui-registration-pins (both "no console build ... this is a broken
gauge, not a passing budget"). None of the three names any file in this diff
(verified with a lit control on the same grep), and this diff changes no README,
no export surface and no bundle.

7. Out of scope, not fixed here

• plugin-list's ListView has the same family of arm, and there it is
  LIVE. ListView.tsx:2060-2067 reads data -> records -> value on its own
  find() answer, and ObjectGallery.expandFls-7429.test.tsx:117 is a live
  find() double emitting { records: [ROW] } that depends on it. Different
  consumer, its own ladder, its own producer — untouched here. It also means the
  repo-wide phrasing "no producer emits records at the DataSource.find()
  seam" is consumer-local, not seam-wide: it is true of this helper's ten
  call sites and false of ListView. Reported to the PM for filing —
  search_issues is hard rate-limited for this session's account
  ("API rate limit already exceeded for user ID 323634890"), and the standing
  rule is not to file unsearched.
• ViewDataProvider's private same-name extractRecords (a third tolerance
  set, records | data | items) is already filed as finding(fields,plugin-detail,plugin-list,app-shell): six more non-QueryResult count/value arms survive the seams #6840 repaired — and one of them reads value AHEAD of data #6917.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YBWFb5YgMU5dw8p2VKj16S

Generated by Claude Code